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Abstract 


Message Tracking is expected to be used to determine the status of 
undelivered e-mail upon request. Tracking is used in conjunction 
with Delivery Status Notifications (DSN) and Message Disposition 
Notifications (MDN); generally, a message tracking request will be 
issued only when a DSN or MDN has not been received within a 
reasonable timeout period. 


This memo defines a MIME content-type for message tracking status in 
the same spirit as RFC 3464, "An Extensible Message Format for 
Delivery Status Notifications". It is to be issued upon a request as 
described in "Message Tracking Query Protocol". This memo defines 
only the format of the status information. An extension to SMTP to 
label messages for further tracking and request tracking status is 
defined in a separate memo. 
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1. Introduction 


Message Tracking is expected to be used to determine the status of 
undelivered e-mail upon request. Tracking is used in conjunction 
with Delivery Status Notifications (DSN) [RFC-DSN-SMTP] and Message 
Disposition Notifications (MDN) [RFC-MDN]; generally, a message 
tracking request will be issued only when a DSN or MDN has not been 
received within a reasonable timeout period. 


This memo defines a MIME [RFC-MIME] content-type for message tracking 
status in the same spirit as RFC 3464, "An Extensible Message Format 
for Delivery Status Notifications" [RFC-DSN-STAT]. It is to be 
issued upon a request as described in "Message Tracking Query 
Protocol" [RFC-MTRK-MTQOP]. This memo defines only the format of the 
status information. An extension to SMTP [RFC-ESMTP] to label 
messages for further tracking and request tracking status is defined 
in a separate memo [RFC-MTRK-SMTPEXT]. 


2. Other Documents and Conformance 
The model used for Message Tracking is described in [RFC-MTRK-MODEL]. 


Message tracking is intended for use as a "last resort" mechanism. 
Normally, Delivery Status Notifications (DSNs) [RFC-DSN-SMTP] and 
Message Disposition Notifications (MDNs) [RFC-MDN] would provide the 
primary delivery status. Only if no response is received from either 
of these mechanisms would Message Tracking be used. 


This document is based on [RFC-DSN-STAT]. Sections 1.3 
(Terminology), 2.1.1 (General conventions for DSN fields), 2.1.2 
("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC 
822) of [RFC-DSN-STAT] are included into this document by reference. 
Other sections are further incorporated as described herein. 


Syntax notation in this document conforms to [RFC-ABNF]. 


The following lexical tokens, defined in [RFC-MSGFMT], are used in 
the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, 
linear-white-space, SPACE, text. The date-time lexical token is 
defined in [RFC-HOSTREQ]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC- 
KEYWORDS]. 
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3. Format of a Message Tracking Status Notification 


A Message Tracking Status Notification (MTSN) is intended to be 
returned as the body of a Message Tracking request [RFC-MTRK-MTQP]. 
The actual body MUST be a multipart/related [RFC-RELATED] with type 
parameter of "message/tracking-status"; each subpart MUST be of type 
"message/tracking-status" as described herein. The multipart/related 
body can include multiple message/tracking-status parts if an MTQP 
server chains requests to the next server; see [RFC-MTRK-MODEL] and 
[RFC-MTRK-MTQP] for more information about chaining. 


3.1. The message/tracking-status content-type 


The message/tracking-status content-type is defined as follows: 


MIME type name: message 

MIME subtype name: tracking-status 

Optional parameters: none 

Encoding considerations: "Vbit" encoding is sufficient and 


MUST be used to maintain readability 
when viewed by non-MIME mail readers. 
Security considerations: discussed in section 4 of this memo. 


The body of a message/tracking-status is modeled after [RFC-DSN- 
STAT]. That body consists of one or more "fields" formatted to 
according to the ABNF of RFC 2822 header "fields" (see [RFC-MSGFMT]). 
The per-message fields appear first, followed by a blank line. 
Following the per-message fields are one or more groups of per- 
recipient fields. Each group of per-recipient fields is preceded by 
a blank line. Note that there will be a blank line between the final 
per-recipient field and the MIME boundary, since one CRLF is 
necessary to terminate the field, and a second is necessary to 
introduce the MIME boundary. Formally, the syntax of the 
message/tracking-status content is as follows: 


tracking-status-content = 
per-message-fields 1*( CRLF per-recipient-fields ) 


The per-message fields are described in section 3.2. The per- 
recipient fields are described in section 3.3. 


3.1.1. General conventions for MTSN fields 
Section 2.1.1 (General conventions for DSN fields) of [RFC-DSN-STAT] 


is included herein by reference. Notably, the definition of xtext is 
identical to that of that document. 
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3.1.2. *-type subfields 


Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is included herein 
by reference. Notably, the definitions of address-type, diagnostic- 
type, and MTA-name type are identical to that of RFC 3464. 


3.2. Per-Message MTSN Fields 


Some fields of an MTSN apply to all of the addresses in a single 
envelope. These fields may appear at most once in any MTSN. These 
fields are used to correlate the MTSN with the original message 
transaction and to provide additional information which may be useful 
to gateways. 


per-message-fields = 
original-envelope-id-field CRLF 
reporting-mta-field CRLF 
arrival-date-field CRLF 
*( extension-field CRLF ) 
3.2.1. The Original-Envelope-Id field 


The Original-Envelope-Id field is defined as in section 2.2.1 of 
[RFC-DSN-STAT]. This field is REQUIRED. 


3.2.2. The Reporting-MTA field 


The Reporting-MTA field is defined as in section 2.2.2 of [RFC-DSN- 
STAT]. This field is REQUIRED. 


3.2.3. The Arrival-Date field 


The Arrival-Date field is defined as in section 2.2.5 of [RFC-DSN- 
STAT]. This field is REQUIRED. 


3.3. Per-Recipient MTSN fields 
An MTSN contains information about attempts to deliver a message to 
one or more recipients. The delivery information for any particular 


recipient is contained in a group of contiguous per-recipient fields. 
Each group of per-recipient fields is preceded by a blank line. 
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The syntax for the group of per-recipient fields is as follows: 


per-recipient-—fields = 


original-recipient-field CRLF 
final-recipient-field CRLF 
action-field CRLF 

status-field CRLF 

[ remote-mta-field CRLF ] 

[ last-attempt-date-field CRLF ] 
[ will-retry-until-field CRLF ] 
*( extension-field CRLF ) 


3.3.1. Original-Recipient field 


The Original-Recipient field is defined as in section 2.3.1 of [RFC- 


DSN-STAT]. 


This field is REQUIRED. 


3.3.2. Final-Recipient field 


The required Final-Recipient field is defined as in section 2.3.2 of 
[RFC-DSN-STAT]. This field is REQUIRED. 


3.3.3. Action field 


The required Action field indicates the action performed by the 
Reporting-MTA as a result of its attempt to deliver the message to 
this recipient address. This field MUST be present for each 
recipient named in the MTSN. The syntax is as defined in RFC 3464. 
This field is REQUIRED. 


Valid actions are: 


failed 


delayed 


delivered 


Allman 


The message could not be delivered. If DSNs have been 
enabled, a "failed" DSN should already have been 
returned. 


The message is currently waiting in the MTA queue for 
future delivery. Essentially, this action means "the 


message is located, and it is here." 


The message has been successfully delivered to the final 


recipient. This includes "delivery" to a mailing list 
exploder. It does not indicate that the message has 
been read. No further information is available; in 


particular, the tracking agent SHOULD NOT attempt 
further "downstream" tracking requests. 
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expanded The message has been successfully delivered to the 
recipient address as specified by the sender, and 
forwarded by the Reporting-MTA beyond that destination 
to multiple additional recipient addresses. However, 
these additional addresses are not trackable, and the 
tracking agent SHOULD NOT attempt further "downstream" 
tracking requests. 


relayed The message has been delivered into an environment that 
does not support message tracking. No further 
information is available; in particular, the tracking 
agent SHOULD NOT attempt further "downstream" tracking 
requests. 


transferred The message has been transferred to another MTRK- 
compliant MTA. The tracking agent SHOULD attempt 
further "downstream" tracking requests unless that 
information is already given in a chaining response. 


opaque The message may or may not have been seen by this 
system. No further information is available or 
forthcoming. 


There may be some confusion between when to use "expanded" versus 
"delivered". Whenever possible, "expanded" should be used when the 
MTA knows that the message will be sent to multiple addresses. 
However, in some cases the delivery occurs to a program which, 
unknown to the MTA, causes mailing list expansion; in the extreme 
case, the delivery may be to a real mailbox that has the side effect 
of list expansion. If the MTA cannot ensure that this delivery will 
cause list expansion, it should set the action to "delivered". 


3.3.4. Status field 


The Status field is defined as in RFC 3464. A new code is added to 
RFC 3463 [RFC-EMSSC], "Enhanced Mail System Status Codes", 


X.1.9 Message relayed to non-compliant mailer" 
The mailbox address specified was valid, but the message has 
been relayed to a system that does not speak this protocol; no 


further information can be provided. 


A 2.1.9 Status field MUST be used exclusively with a "relayed" Action 
field. This field is REQUIRED. 
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3.5. Remote-MTA field 


The Remote-MTA field is defined as in section Reference 2.3.5 of 
[RFC-DSN-STAT]. This field MUST NOT be included if no delivery 
attempts have been made or if the Action field has value "opaque". 
If delivery to some agent other than an MTA (for example, a Local 
Delivery Agent) then this field MAY be included, giving the name of 
the host on which that agent was contacted. 


3.6. Last-Attempt-Date field 


The Last-Attempt-—Date field is defined as in section Reference 2.3.7 
of [RFC-DSN-STAT]. This field is REQUIRED if any delivery attempt 
has been made and the Action field does not have value "opaque", in 
which case it will specify when it last attempted to deliver this 
message to another MTA or other Delivery Agent. This field MUST NOT 
be included if no delivery attempts have been made. 


-3.7. Will-Retry-Until field 


The Will-Retry-Until field is defined as in section Reference 2.3.9 
of [RFC-DSN-STAT]. If the message is not in the local queue or the 
Action field has the value "opaque" the Will-Retry-Until field MUST 
NOT be included; otherwise, this field SHOULD be included. 


-4. Extension fields 


Future extension fields may be defined as defined in section 2.4 of 
[RFC-DSN-STAT]. 


-5. Interaction Between MTAs and LDAs 


A message that has been delivered to a Local Delivery Agent (LDA) 
that understands message tracking (in particular, an LDA speaking 
LMTP [RFC-LMTP] that supports the MTRK extension) SHOULD pass the 
tracking request to the LDA. In this case, the Action field for the 
MTA->LDA exchange will look the same as a transfer to a compliant 
MTA; that is, a "transferred" tracking status will be issued. 


Security Considerations 
1. Forgery 
Malicious servers may attempt to subvert message tracking and return 


false information. This could result in misdirection or 
misinterpretation of results. 
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4.2. Confidentiality 


Another dimension of security is confidentiality. There may be cases 
in which a message recipient is autoforwarding messages but does not 
wish to divulge the address to which the messages are autoforwarded. 
The desire for such confidentiality will probably be heightened as 
"wireless mailboxes", such as pagers, become more widely used as 
autoforward addresses. 


MTA authors are encouraged to provide a mechanism which enables the 
end user to preserve the confidentiality of a forwarding address. 
Depending on the degree of confidentiality required, and the nature 
of the environment to which a message were being forwarded, this 
might be accomplished by one or more of: 


(a) respond with a "relayed" tracking status when a message is 
forwarded to a confidential forwarding address, and disabling 
further message tracking requests. 

(b) declaring the message to be delivered, issuing a "delivered" 
tracking status, re-sending the message to the confidential 
forwarding address, and disabling further message tracking 
requests. 

The tracking algorithms MUST NOT allow tracking through list 

expansions. When a message is delivered to a list, a tracking 

request MUST respond with an "expanded" tracking status and MUST NOT 
display the contents of the list. 

5. IANA Considerations 
IANA has registered the SMTP extension defined in section 3. 
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